어느덧 입사한 지 1년이 지났다. 첫 회사이니만큼 잘하고 싶은 마음에 이것저것 더 하려고 했던 것 같다. 뭔가 더 해야 할 것 같고, 증명해야 할 것 같고, “내가 잘한다!”라는 걸 동료들에게 알리고 싶은 마음이 컸다. 하지만 마음처럼 되지 않았던 부분이 많았다. 마음만 급하다 보니 실수가 잦았고, 많은 맥락을 가지려고 하다 보니 우선순위를 제대로 정하지 못했다. 급한 리팩토링으로 모듈과 제품의 영향 범위를 고려하지 못해 시간이 지난 뒤 사이드 이팩트를 만난 적도 있었다.

그런 와중에 두 가지 계기가 생겼다. 우선, 팀에서 새롭게 떠오르는 키워드가 생겼다. 팀원이 바뀌고 팀의 방향성을 논의하는 과정에서 중요한 갈래 중 하나로 “요구사항 문서 정리하기”가 나왔다. 또 다른 계기로 토스 Head of FE 박서진 님의 인터뷰 ([디버깅 전문가를 만나다] 1. 토스 Head of FE 박서진 님)을 읽게 된 것이었다.

두 가지 계기를 바탕으로 하반기에 새로운 시도를 시작했다. 한마디로 정리하면 “코드 작성하기 전에 생각 정리하기”라고 할 수 있겠다.

• 요구사항 문서 정리하기
• 디버깅 행동 지도 그리기
• 구두 논의하기

내가 잘못하고 있던 부분

스프린트(프로젝트)처럼 큰 단위의 작업이 시작되거나 CS 이슈 처리와 같은 간단한 작업을 받으면 나는 “어떻게 하면 빠르게 문제를 해결할 수 있을까?”에 초점을 두었다. 곧바로 vscode를 켜서 요구사항을 코드로 구현하려고 했다. 이미 비슷한 문제를 해결했던 사례를 찾아 코드를 살짝 수정해서 복사하고 붙였다. 그리고 실행시켜서 잘 안되면 또 다른 코드 조각으로 문제를 해결하려고 했다.

기능 구현에만 집중하다 보니 문제가 된 경우가 많았다. 도메인에 대한 이해 없이 중복처럼 보이는 코드를 공통 모듈로 공통화했는데 나중에 문제를 겪기도 했고, 인프라 설정 과정에서 이해 없이 비슷한 코드를 복붙하다가 디버깅하는 데 어려움을 겪은 적도 있었다. 구체적인 사례가 아니더라도 내 결과에 대한 퀄리티가 낮아졌다. 자잘한 실수, 낮은 QA 퀄리티, 배포 이후 버그 픽스 등 하나의 일을 Done 처리하기 위해 추가 작업이 계속 이어졌다. 이러한 실수들은 결국 한 번에 문제를 끝내는 대신 추가적인 작업을 필요하게 했다.

이런 비효율적인 개발 과정을 개선하기 위해 3가지 시도를 해봤다.

시도1: 요구사항 문서 정리

요구 사항을 정리하면서 자연스럽게 일정 산정에 대한 자신감이 생겼다. 이전에는 ‘이번 주까지 완료할 수 있을 것 같다’고 예상했지만, 곧 다른 작업이 끝나지 않거나 예상치 못한 부분에서 추가 개발이 필요해지는 경우가 종종 있었다. 하지만 요구사항을 정리하면서 많은 부분에서 개선할 수 있었다.

요구사항을 정리하는데 정해진 방법은 없다고 생각한다. 여러 페이지에 걸쳐 있는 복잡한 유저플로우 수정, 한 화면에 여러 가지 기능이 있는 페이지 개선, 공통 모듈 버전업하기 등등 각 작업에 따라 고려해야하는 부분이 다르기 때문이다. 그래서 나만의 방법으로 집중한 부분을 정리해보려고 한다.

플로우 및 요구사항 정리하기

요구사항을 정리하고, 유저 플로우를 다이어그램 같은 툴을 활용해 시각화했다. 이전에는 다른 사람이 작성한 문서(디자인 시안이나 프로젝트 요구사항 문서)에 의존해 개발했기 때문에, 세부적인 흐름이나 UX적인 부분을 놓치는 경우가 많았다.

요구사항을 주도적으로 정리하다보면 작업을 작은 단위로 나눌 수 있게 된다. 하나의 큰 덩어리에서 볼 수 없었던 각 작업 별로 풀어야하는 문제가 명확해진다. 잘 나뉜 작업은 이후 이어지는 의존성과 영향 범위에도 영향을 끼친다.

가능하면 코드에 테스트 케이스로 나타내려고 했다. 코드 베이스에 반영하지 않더라도 테스트를 작성하는 것만으로도 모듈 간 역할과 책임에 대해서 한 번 더 고민하게 된다는 장점이 있었다.

// 퍼널에 대한 테스트
it.todo('로그인한 유저라면, 000 퍼널로 이동한다.', () => {})
it.todo('로그인하지 않은 유저라면, 000 퍼널로 이동한다.', () => {})

// 특정 컴포넌트에 대한 테스트
it.todo('', () => {})

// 훅에 대한 테스트
it.todo('정의되어 있지 않은 규칙을 입력했을 때, 반환 값에 포함하지 않는다.', () => {})

의존성이 있는 작업파악하기

작업을 병렬로 진행하려면 의존성 있는 작업을 미리 파악해야 한다. 여러 이해관계자와 협업하다 보면 어떤 작업이 오래 걸릴지, 혼자 할 수 있는 일은 무엇인지 파악하는 것이 일정 산출에 도움이 된다. 의존성 있는 작업을 먼저 요청하고 나 혼자 할 수 있는 일을 진행했다. 예를 들어, 서버 개발자와 작업할 때 인터페이스 논의를 먼저 해서 구현 없이도 시작할 수 있게 하고, 공통 컴포넌트 수정이 필요하면 프론트엔드 팀원들과 미리 논의했다.

제품 영향 범위 파악하기

도메인에 대한 이해도 중요하다. 도메인을 완벽하게 이해하지 않아도 기능은 구현할 수 있다. 하지만 도메인을 이해해야 수정하거나 개선할 수 있다. 직접적인 연관은 없더라도 내가 수정하고 추가하는 부분이 제품 전체에 어떤 영향을 미칠지 정리했다.

시도2: 디버깅 행동 지도 그리기

자세한 내용은 아래 링크를 참고하면 된다. 인터뷰에 나온 내용을 거의 그대로 해보려고 했다. “디버깅 행동 지도 그리기”라는 용어도 인터뷰 내용에서 그대로 가져왔다.

인터뷰 내용을 바탕으로 “디버깅 행동 지도 그리기”를 실천해보려고 했다. 요약하자면, 디버깅 과정에서도 메타인지가 중요하다고 할 수 있다.

올바르게 동작하다면 어떤 순서로 연산이 일어나야 하는지 생각한다.

처음엔 올바른 순서를 떠올리지 못하거나, 착각하는 경우도 많았다. 이 때, 두 가지 포인트에서 고민할 수 있었다.

• 기술적인 맥락이 부족한가?
• 도메인 맥락이 부족한가?

기술적인 부분은 관련 기술을 찾아볼 수 있고, 도메인이 부족하다면 슬랙과 노션을 찾아보며 맥락을 파악할 수 있다. 순서를 떠올릴 수 있다면 실제 동작하는 과정과 비교해보면서 어느 부분에서 다르게 생각했는지 확인하면서 버그를 수정했다.

이러한 과정없이 바로 버그를 수정할 수 있지만, 일련의 과정을 거친 뒤 내가 어느 부분이 부족하고 뭘 더 해야겠다는 방향을 잡을 수 있었다.

시도3: 팀원들에게 PR올리기 전에 구두로 논의하기

작업을 시작하기 전에 전체적인 흐름을 팀원들에게 공유하는 과정을 가졌다. PR 리뷰에서 코드를 통해 받을 수 있는 피드백은 생각보다 제한적이다. 설계에 대한 피드백을 받고 싶을 때는, 직접 대화를 통해 구체적인 맥락을 설명하고 “이런 배경이 있고, 저는 몇 가지 선택지 중에 00을 선택했어요. 혹시 다른 방법이나 의견 주실 수 있으실까요?” 등과 같은 질문을 던졌다.

이러한 방식으로 더 빠르게 피드백을 받을 수 있었다. 코드를 작성하고 PR 리뷰를 통해 피드백을 받는 과정보다, 설계 단계에서 의견을 먼저 나누니 피드백 주기가 짧아졌고, 전체적인 코드의 방향성에 대한 팀원들의 이해도도 높아졌다.

코드를 작성하기 전에 챙길 수 있었던 것들

요구사항 문서정리, 디버깅 행동 지도 그리기, 팀원들과 구두 논의는 모두 개발 과정에서 중요한 역할을 했다.

• 요구사항을 주도적으로 정리하기
• 모듈간 역할과 책임에 대해 한 번 더 고민하기
• 의존성 있는 작업을 파악해서 병렬적으로 작업하기
• 제품에 미치는 영향을 고려하기
• 디버깅 과정에서 기술적, 도메인적인 면에서 부족한 부분 파악하기
• 생각을 정리해서 전달하고, 피드백 사이클 줄이기

더 나아가서

물론 이 모든 원칙을 항상 지키면서 개발하고 있지는 않다. 급할 때는 나도 바로 vscode를 켜거나 AI 도구에 의존할 때도 많다. 하지만 작업을 시작하기 전에 한 번 더 고민하고, 이런 습관이 내 개발 과정에 자연스럽게 녹아 들도록 노력하고 있다.